Skip to main content

Deploying SmartBridge Core

SmartBridge Core is a product that just performs CAC authentication and CRL checking. The Core product does not include:

  • Multi-Factor authentication: the ability to scan a QR code with an authenticator app and for SmartBridge to validate a Time-based One Time Passcode
  • Simulated CAC certificates: the ability to generate certificates developers can use to test CAC based features without actually having a CAC. Certificates can be downloaded and installed to a desktop OS

System Architecture of SmartBridge CORE​

Pre-requisites​

  • Kubernetes Cluster. Smartbridge works best in a minimum of 3-worker cluster and needs the equivalent of 6 vCPUs and 24 GiB of RAM total

    • Worker nodes will need permissions to an AWS secret. The simplest method is to attach a policy to the AWS Role used by worker nodes (outlined below)

    • SmartBridge requires 2 Persistent Volume claims of approx 10 GiB each

  • Port 443 must be available on the cluster to serve mTLS traffic.

  • A TCP pass-through route to the cluster over port 443 for mTLS traffic. In AWS, this can be accomplished with a Network Load Balancer with TCP pass-through.

  • Permission to egress to the DISA website hosting CRLs (https://crl.gds.disa.mil/getcrlzip?ALL+CRL+ZIP)

  • A subdomain for CAC traffic, e.g. cac.yoursite.com, and a permitted route to the cluster over port 443.

    • NOTE: this may also be possible using a "slug", such as yoursite.com/cac. SmartBridge does not forward or re-route traffic, so the host system will need to route /cac traffic to SmartBridge and all other traffic to other appropriate locations).

  • Access to the key and certificate for the URL that will serve CAC authentication traffic (e.g. cac.yoursite.com)

  • Set-up of SmartBridge with credentials to the identity provider (a client_id and client_secret). These are used to authenticate the SmartBridge system when posting data about CAC authentications back to the identity provider.

  • SmartBridge and 3rd party images loaded into MOTAR's image repository, specifically:

    • SmartBridge CAC Interceptor
    • SmartBridge CRL Manager
    • SmartBridge Revocation Checker
    • ingress-nginx/controller:v1.7.0
    • minio:2021.5.27-debian-10-r0
    • minio-client:2021.5.26-debian-10-r0
    • hub.docker.com/stakatar/reloader:v0.0.94
    • hub.docker.com/redis:6.2.1-alpine

  • Helm - use helm to deploy SmartBridge

  • AWS CLI Access

  • Kubectl access to the cluster

Deploying SmartBridge​

  1. Create a secret in AWS Secrets Manager called smartbridge/{unique-name}. The script in helm/smartbridge/aws-secrets/create-secrets-template.sh uses the AWS CLI to create the secret with the appropriate values. Before running the script, you need:

    * AWS authentication profile with permissions to create and/or update a secret in AWS Secrets Manager

    * A unique name for the smartbridge installation - this could be the EKS cluster name if deployed to its own cluster, or the name of an environment, e.g. "dev". The full secret name will be "smartbridge/{your-unique-name}

    * The client secret the SmartBridge app (plug-in) from MOTAR Studio.

    * The private key and public SSL certificate files for the domain that will handle CAC authentication

    * Registry credentials to allow SmartBridge to pull images from an image repository

  2. Create the following IAM policy in AWS and attach it to the role the Kubernetes workers use. This permits the SmartBridge containers access to the secret in AWS Secrets Manager. Use the AWS region you are deploying to and your account id. Replace the "*" with the unique name you set for the secret above:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SmartBridgeSecretAccess",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "arn:aws-us-gov:secretsmanager:{AWS-REGION-ID}:{YOUR-AWS-ACCOUNT-ID}:secret:smartbridge/*"
        }
    ]
}

  1. Use helm to deploy the SmartBridge nginx controller:

    • Navigate to the nginx deployment folder under helm/nginx

    • Create the kubernetes namespace with kubectl create namespace sb-ingress-nginx

    • Create a kubernetes secret for the truststore (Note: the truststore itself contains nothing secret, but the TLS secret type was the best way to manage the truststore). Run kubectl apply -n sb-ingress-nginx -f truststore.yaml

    • Deploy the helm chart with helm upgrade --install sb-nginx -n sb-ingress-nginx -f values .

  2. Use helm to deploy SmartBridge:

    • Navigate to the SmartBridge folder under helm/smartbridge

    • Create the namespace for SmartBridge with kubectl create namespace smartbridge

    • Create the secrets in Kubernetes SmartBridge needs [Process / Script TBD]

    • Create the configmap (via helm values file) SmartBridge needs [Process / Script TBD]

    • Deploy the helm chart with helm upgrade --install smartbridge -n smartbridge -f values/values_YOUR-UNIQUE-NAME.yaml .

A note about 3rd party dependency upgrades:​

Over the coming months, these components will be upgraded as follows:

  • minio will upgrade to quay.io/minio/minio:RELEASE.2023-04-28T18-11-17Z
  • minio-client will upgrade to quay.io/minio/mc:RELEASE.2023-04-12T02-21-51Z
  • hub.docker.com/stakatar/reloader will upgrade to hub.docker.com/stakater/reloader:v1.0.24
  • hub.docker.com/redis:6.2.1-alpine will upgrade to redis:6.2, then 7-alpine